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Executive  Summary 


In  order  to  address  the  needs  of  tomorrow’s  National  Airspace  System  (NAS)  users,  the  Federal 
Government  is  implementing  the  Next  Generation  Air  Transportation  System  (NextGen).  The 
success  of  NextGen  will  rely,  in  part,  on  the  ability  to  provide  the  right  information  to  the  users 
that  need  it,  when  they  need  it.  NextGen  is  implementing  a  net-centric  environment  to  ensure 
that  relevant,  accurate,  timely,  and  well-understood  information  is  available  to  any  authorized 
consumer  and  irrelevant  information  is  filtered  out.  The  ability  to  precisely  direct  information  to 
users  is  accomplished  through  the  use  of  ontologies  and  semantic  technologies.  An  ontology  is  a 
set  of  terms,  arranged  hierarchically,  that  represent  the  real  world  objects  and  processes  within  a 
given  domain  (e.g.,  weather,  surveillance,  and  safety)  that  has  been  encoded  in  a  formal, 
machine-readable  language.  Within  the  context  of  information  sharing,  the  ontology  is  used  to 
more  precisely  define  the  meaning  of  an  organization’s  data  elements  and  attributes.  The 
ontology  provides  the  basis  for  a  semantic  search  capability  that  goes  well  beyond  simple 
keyword  searches  to  searches  that  take  into  consideration  the  meanings  of  the  search  term  (e.g.  a 
search  for  “dog”  should  find  items  that  contain  the  word  “canine”  since  they  mean  the  same 
thing).  Ontologies  are  a  key  to  effective  information  sharing  across  multiple  communities  with 
varying  terminologies  and  operational  needs. 

This  document  describes  the  approach  used  by  the  Joint  Planning  and  Development  Office 
(JPDO)  Net-Centric  Operations  Division  (NCOD)  in  sponsoring  the  development  of  ontologies 
and  encouraging  ontology  implementation  in  support  of  Net-Centric  information  exchanges.  This 
approach  uses  small,  agile  development  teams,  called  Community  of  Interest1  (COI)  Engagement 
Teams,  to  create  an  inter-organizational  environment  that  is  efficient,  sustainable,  and  extensible. 
This  document  outlines  a  typical  NCOD  engagement  with  a  COI  or  Working  Group  (WG)  and 
defines  a  set  of  products  that  result  from  a  typical  engagement. 

This  document  has  been  composed  to  reflect  the  actual  approach  and  processes  that  worked  for 
the  COI  Engagement  Teams  during  engagements  with  the  Weather  and  Integrated  Surveillance 
communities.  As  a  result,  this  document  is  based  upon  the  actual  experiences  of  the  teams. 

The  NextGen  Net-Centric  Concept  of  Operations2  articulates  the  need  for  interoperable  systems 
to  implement  NextGen.  This  Community  of  Interest  (COI)  Engagement  Plan  is  intended  to  build 
on  these  documents  as  well  as  the  AF  COI  Primer  VIA)  and  the  Concept  of  Operations  for  the 


1  DOD  Directive  8320.2  defines  a  Community  of  Interest  as  “A  collaborative  group  of  people  that  must  exchange 
information  in  pursuit  of  its  shared  goals,  interests,  missions,  or  business  processes  and  therefore  must  have  a  shared 
vocabulary  for  the  information  it  exchanges.”  A  COI  does  not  need  to  be  chartered  or  formally  structured  to  be 
considered  a  COI. 

2  Next  Generation  Air  Transportation  System  (NextGen)  Net-Centric  Concept  of  Operations  VO. 7  December  2009 

3  US  Air  Force  Community  of  Interest  Primer  Version  1.0,  dated  12  July  201 1 


Joint  Planning  and  Development  Office 


NextGen  Air  Transportation  System4.  Key  tenets  of  the  NCOD  approach  to  improving 
interoperability  include: 


•  Identifying  and  analyzing  an  organization’s  core  information  exchanges.  Core 
information  exchanges  are  real-world  or  planned  exchanges  between  entities  (such  as 
persons,  aircraft,  and  systems).  The  information  being  exchanged  may  deal  with  real- 
world  events  (such  as  flights,  security  incidents  and  weather  phenomena)  that  play 
essential  roles  in  the  organization’s  operations,  or  may  deal  with  planned  events  (such  as 
flight  schedule  information  and  flight  plans).  Note  that  core  information  exchanges 
should  include  both  actual  information  exchanges  in  place  today  and  information 
exchanges  required,  or  reasonably  expected  to  be  required,  based  on  the  NextGen 
architecture,  the  Joint  Planning  Environment  (JPE),  implementation  roadmaps,  and  other 
planning  documents.  This  will  require  the  COI  participants  (both  permanent  and  adjunct 
members)  to  be  fully  knowledgeable  about  NextGen  plans  and  capable  of  envisioning  the 
“to  be”  environment  without  being  overly  captive  to  “as  is”  thinking.  The  NCOD 
approach  is  to  analyze  the  key  elements  and  relationships  in  the  organization’s  core 
information  exchanges  and  to  represent  them  in  a  formal,  standardized  model,  called 
an“ontology.”  As  part  of  the  analysis,  the  COI  Engagement  Team  generally  prepares 
selected  Department  of  Defense  (DOD)  Architecture  Framework  (DODAF)  products  (see 
Section  4.2  for  more  information).  The  COI  participants  would  be  responsible  for  both 
registering  existing  services  and  databases  with  the  potential  to  become  services,  and 
identifying  services  that  NextGen  requires,  or  that  would  help  to  facilitate  NextGen.  If 
deemed  appropriate,  the  COI  participants  may  also  formulate  a  plan  for  developing  those 
services  that  NextGen  needs  but  does  not  currently  have. 

•  Agile  Development.  NCOD  deploys  COI  Engagement  Teams,  which  are  small,  cross¬ 
functional  teams  that  can  rapidly  conduct  the  appropriate  analyses  to  develop  the 
NextGen  Enterprise  Ontology,  which  is  a  compilation  of  NextGen  COI  Ontologies. 

These  COI  Engagement  Teams  can  respond  quickly  to  changing  requirements,  making 
continuous  improvements  over  successive  development  cycles.  The  use  of  COI 
Engagement  Teams  is  intended  to  jump  start  the  overall  COI  development  process  in  an 
environment  where  there  are  disparate  stakeholders,  a  breadth  of  NextGen  requirements, 
wide-ranging  functional  knowledge  requirements,  and  varying  levels  of  COI  or  WG 
maturity. 

•  Ontology  driven  service  generation.  The  COI  Engagement  Teams  define  key  terms  first 
in  an  ontology  language  (e.g.,  RDF/OWL).  If  messages  are  needed,  then  a  message 
schema  (in  XML,  for  instance)  that  is  based  on  the  ontology  can  be  created.  The  ontology 
provides  the  single  semantic  framework  that  supports  the  information-sharing  needs  of  a 
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COI  within  the  context  of  NextGen.  All  message  schemas  should  tie  back  to  the 
ontology,  so  that  the  ontology  provides  the  means  for  interpreting  information  from  other 
agencies  or  communities  that  use  terms  differently.  In  some  cases,  services  may  already 
exist,  and  it  will  be  necessary  to  reverse  engineer  these  services  to  conform  to  the 
ontology -driven  service  generation  approach.  This  entails,  among  other  things,  a  mapping 
from  existing  schemas  to  the  ontology. 
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1.0  Purpose 

This  document  describes  the  approach  used  by  the  Joint  Planning  and  Development  Office 
(JPDO)  Net-Centric  Operations  Division  (NCOD)  to  facilitate  the  implementation  of  efficient, 
sustainable,  and  reusable  inter-organizational  information-exchange  services  within  a  SSOA.  It 
outlines  a  typical  engagement  between  an  NCOD  COI  Engagement  Team  and  a  NextGen 
Community  of  Interest  (COI)  or  working  group  (WG)  and  describes  the  set  of  products  that 
result  from  a  typical  engagement.  These  products  will  then  be  used  by  the  NextGen  partner 
agencies  to  implement  their  information  exchange  services. 

For  some  engagements,  the  process  may  be  tailored  specifically  for  that  engagement.  In  those 
cases,  the  process  may  vary  somewhat  from  what  is  described  in  this  document.  For  example,  the 
Weather  WG  asked  the  COI  Engagement  Team  to  focus  on  the  As-Is  products,  so  To-Be  views 
were  not  created  for  the  initial  weather  engagement.  The  To-Be  views  may  be  created  in  a  future 
development  cycle. 


2.0  Introduction 

The  NextGen  initiative  was  mandated  by  Congress  to  modernize  the  U.S.  Air  Transportation 
System  in  order  to  increase  capacity  and  reliability,  improve  safety  and  security,  and  minimize 
the  environmental  impact  of  aviation.  The  required  improvements  to  the  air  transportation 
system  are  to  be  achieved  through  space-based  navigation,  digital  communications,  layered 
adaptive  security,  and  net-centric  information  access  for  operations. 

The  mission  of  the  NCOD  is  to  manage  policies  and  strategies  for  information  sharing  and  to 
coordinate  investment  and  development  of  network-enhancing  capabilities  in  support  of 
NextGen.  Effective  information  sharing  is  crucial  to  maximizing  the  value  of  an  organization's 
information  assets,  reducing  costs  through  reuse  and  agile  architecture,  and  leveraging  an 
organization's  know-how.  While  larger  and  more  diverse  enterprises  create  greater  information 
sharing  challenges,  they  also  offer  considerable  benefits. 

Some  of  these  information- sharing  challenges  arise  because  different  groups  may  use  different 
terminologies  to  describe  the  same  things,  or  the  same  terminology  to  describe  different  things. 
Critical  knowledge  may  remain  locked  in  peoples’  heads  or  buried  in  application  code.  Potential 
synergies  can  be  lost  because  information  remains  isolated  and  disconnected.  NCOD  and  the 
COI  Engagement  Teams  apply  Semantic  Web  technologies  (such  as  ontologies)  to  overcome 
these  barriers  to  information  sharing.  Key  attributes  of  the  net-centric  information-sharing 
environment  envisioned  for  NextGen  include: 

•  Services  that  are  discoverable,  accessible,  and  well-annotated 

•  Data  that  are  understandable,  accurate,  and  timely 

•  Published  service-level  agreements 
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•  Secure  and  collaborative  information- sharing  environment5 

This  document  outlines  a  strategy  for  working  with  COIs  and  WGs  to  identify  and  provision 
high-value  information-exchange  services  that  will  meet  these  criteria  and  improve  both 
situational  awareness  and  operational  efficiency  across  NextGen. 

JPDO  recommends  the  use  of  an  iterative  methodology  with  respect  to  interacting  with 
individual  COIs.  There  are  a  number  of  NextGen  COIs  that  the  COI  Engagement  Team  needs  to 
work  with,  but  the  Team’s  time  is  limited.  Rather  than  attempting  to  capture  all  of  a  particular 
COI’s  information  elements  upfront  (which  would  take  a  significant  amount  of  time  during 
which  other  COIs  would  be  waiting),  the  COI  and  the  COI  Engagement  Team  select  a  few  high- 
payoff  information  exchanges  to  focus  on  for  the  first  round  and  build  out  the  ontology  for  those 
information  exchanges.  Once  that  iteration  is  completed,  there  is  typically  a  period  of  time  where 
the  COI  is  evaluating  and  vetting  the  results  of  that  iteration  within  the  COI  to  determine  what,  if 
any,  revisions  need  to  be  made  to  the  ontology.  While  the  COI  is  vetting  the  ontology,  the  COI 
Engagement  Team  moves  on  to  work  with  a  different  NextGen  COI.  When  the  COI  Engagement 
Team  returns  to  work  with  the  first  COI  for  the  second  iteration,  they  address  any  necessary 
revisions,  and  then  move  on  to  analyze  the  next  set  of  high-payoff  information  exchanges. 
Through  this  iterative  process,  with  each  additional  iteration  for  a  COI,  the  COI  ontology  (and  by 
extension,  the  NextGen  Enterprise  Ontology)  becomes  more  comprehensive. 

2. 1  Ontology-based  Information  Services 

The  COI  Engagement  focuses  on  an  analysis  of  the  information  exchanges  that  are  central  to  an 
organization’s  business  or  mission.  The  COI  Engagement  Team  will  work  with  the  COI’s 
Subject  Matter  Experts  (SMEs)  to  identify  those  information  exchanges.  The  COI  Engagement 
Team  will  then  either  reuse  an  existing  COI  domain  ontology6  by  registering  the  ontology  in  the 
NextGen  Service  Metadata  Catalog,  or  if  a  domain  ontology  does  not  exist,  the  COI  Engagement 
Team  will  work  to  produce  and  register  an  ontology.  The  ontology  will  then  be  aligned  with  the 

n 

NextGen  Enterprise  Ontology.  When  fully  completed,  the  ontology  will  represent  a 
comprehensive  set  of  information  about  the  attributes  of  the  objects  and  operational  activities 
that  are  important  to  the  COI  as  a  whole.  Since  the  COI  Engagement  Teams  are  following  an 
iterative  schedule,  they  are  building  the  COI  ontologies  incrementally  through  repeated  iterations 
with  each  COI.  This  development  methodology  focuses  on  working  with  the  high-payoff 
information  exchanges  first,  but  also  means  that  the  early  versions  of  the  COI  ontologies  will  not 
be  all-encompassing. 


5  Department  of  Defense  Net-Centric  Data  Strategy,  May  9,  2003. 

6  An  ontology  is  a  formal,  machine-readable  representation,  or  model  that  associates  an  organization’s  data  elements 
with  the  real-world  entities. 

7  Note  that  the  detailed  procedures  for  how  an  element  goes  from  the  COI  domain  ontology  to  the  NextGen 
Enterprise  Ontology  still  need  to  be  worked  out. 
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A  COI  domain  ontology  is  a  structured  representation  of  the  types  of  entities  and  relations 
existing  within  a  given  domain  that  is  designed  to  support  exchange  and  reuse  of  data  and 
information.  It  is  not  intended  to  be  a  highly- specific  data/information  model  that  is  tied  to  a 
particular  type  of  implementation.  The  COI  domain  ontology  describes  how  things  are  in  the 
world,  but  not  how  they  are  used  or  constrained  within  a  closed  information  system.  This  means 
that  different  information  systems  can  use  the  same  ontology  to  describe  the  meaning  of  their 
data  without  having  to  harmonize  and  deconflict  the  syntax  of  each  other’s  information  models. 
For  instance,  the  Weather  COI  domain  ontology  contains  elements  such  as  wind  speed,  wind 
direction,  and  cloud  type.  It  assigns  a  definition  and  Universal  Resource  Identifier  (URI)  to  each 
element,  but  it  does  not  assign  datatypes  (which  may  be  platform-specific)  to  them,  as  one  would 
in  a  data/information  model.  This  lack  of  specificity  to  a  particular  type  of  implementation  is 
what  makes  ontologies  useful  tools  for  understanding  and  using  heterogeneous  datasets. 

One  of  the  advantages  of  the  ontology  is  that  it  can  be  both  human  and  machine -readable. 
Another  advantage  of  the  ontology  is  that  it  does  not  make  any  rigid  commitments  with  respect 
to  syntax  but  rather  can  accommodate  a  variety  of  implementation  platforms.  Consequently,  the 
ontology  provides  support  for  service  discovery  capabilities  that  are  not  tied  to  any  particular 
programming  language  or  database  management  system,  and  that  enable  potential  information 
consumers  to  search  for  appropriate  data  resources  even  if  they  are  not  familiar  with  the 
particular  linguistic  conventions  of  the  service  provider.  An  example  may  clarify  how  the 
ontology  performs  this  function.  Let’s  say  that  you  are  interested  in  finding  all  services  across 
multiple  agencies  that  have  some  relationship  to  the  term  “dog,”  which  is  the  term  that  is  used  in 
your  agency.  Some  of  the  other  agencies,  however,  may  use  the  term  “canine.”  A  simple 
keyword  search  would  not  include  the  services  from  those  agencies  in  your  result  set  because 
they  don’t  use  the  term  “dog.”  But  if  you  have  an  ontology  that  defines  “canine”  as  the 
equivalent  of  “dog,”  an  ontologically-aware  search  will  return  services  that  use  either  term.  This 
is  how  an  ontology  enhances  the  discovery  of  services.  Likewise,  an  ontology  can  filter  out 
unwanted  results,  such  as  “hot  dog”  which  is  not  semantically  related  to  “dog.” 

2.2  Describing  and  Provisioning8  Information  Services 

The  COI  engagement  process  focuses  on  the  identification  of  information  exchanges.  In  some 
cases,  these  will  be  existing  information  exchanges  that  are  already  represented  in  services.  In 
other  cases,  these  will  be  information  exchanges  that  have  been  identified  as  necessary  or  helpful 
for  NextGen  implementation  even  though  they  do  not  currently  exist. 

For  those  cases  where  there  is  an  existing  service,  the  information  exchanges  may  be  provisioned 
at  one  of  three  levels  as  described  below. 


8  Provisioning  refers  to  providing  and  registering  metadata  and  other  explanatory  material  about  a  service  in 
conjunction  with  registering  that  service  for  reuse. 
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Level  I  -  Create  Service  Metadata  Card 


In  order  to  register  a  service  in  the  NextGen  Semantic  Metadata  Catalog,  one  must  complete  a 
Service  Metadata  Record.  The  Service  Metadata  Record  contains  the  following  metadata 
elements9: 


dc10:contributor 
dc:  coverage 
dc:creator 
dc:date 
dc:description 
dc:  format 
dc:  identifier 
dcdanguage 
dc  publisher 
dc  relation 
dc:rights 
dc:  source 
dc:subject 
dc:  title 
dc:type 

foaf 1 1  :primaryTopic 
icism12:classification 

i  o 

meta  :pointOfContact 


Level  I  provisioning  is  mandatory  for  registration  in  the  NextGen  Semantic  Metadata  Catalog, 
and  is  intended  to  allow  external  participants  to  register  their  services  even  if  they  have  not  gone 
through  the  COI  Engagement  process,  which  results  in  a  fully-provisioned  service.  The  Semantic 
Metadata  Portal  would  provide  this  functionality.  As  for  the  detailed  elements,  at  this  time  no 
decision  has  been  made  with  respect  to  which  metadata  elements  are  mandatory  and  which  are 
optional.  Also,  additional  artifact  specific  metadata  elements  may  be  added  as  needed. 


9  Note  that  some  of  these  metadata  elements  will  be  mandatory  and  some  will  be  optional.  Detailed  decisions  about 
which  will  be  mandatory  or  optional  have  not  yet  been  made. 

10  The  “dc”  prefix  identifies  a  data  element  as  part  of  the  Dublin  Core  metadata  set,  a  small  group  of  fundamental 
elements  that  can  describe  and  catalog  most  resources. 

1 1  The  “foaf’  prefix  identifies  a  data  element  as  part  of  the  “Friend  of  a  Friend”  ontology  that  describes  people,  their 
activities,  and  their  relationships  to  other  people  and  objects. 

12  The  “icism”  prefix  identifies  a  data  element  as  part  of  the  Intelligence  Community  Information  Security  Marking 
Metadata  set. 

13  The  “meta”  prefix  identifies  a  data  element  that  was  created  for  the  NextGen  Enterprise  Ontology. 


Joint  Planning  and  Development  Office 


4 


JPDO  Net-Centric  Operations  Division 

Community  of  Interest  Engagement  Plan 


Level  II  -  Semantic  Provisioning 

A  semantically-provisioned  service  is  one  that  is  registered  in  the  NextGen  Semantic  Metadata 
Catalog  (as  described  for  Level  I  Provisioning  above).  In  addition,  Level  II  Provisioning 
generally  includes: 

•  A  mapping  from  message  data  elements  (e.g.  XML  schema  components)  to  ontology 
elements  in  the  NextGen  Enterprise  Ontology.  (These  mappings  are  currently  done 
through  the  use  of  semantic  tags14) 

•  A  representation  of  the  service  using  one  or  more  of  the  following  service 
ontologies15: 

o  Minimal  Service  Model  (MSM) 

o  Semantic  Annotations  for  WSDL  and  XML  Schema  (SAWSDL) 
o  Web  Service  Modeling  Ontology  Lite  (WSMO-Lite) 
o  HTTP  Vocabulary 

Level  III  -  Operation  and  System  Provisioning  (e.g.  Full  Provisioning) 

A  fully-provisioned  service  must  also  include  supporting  documentation  about  the  following 
aspects  of  the  service: 

•  Documented  performance  characteristics  and  delivery  infrastructure 

•  Documented  cyber- security  considerations 

•  Documented  business  rules  governing  the  exchange  of  information,  such  as  Quality 
of  Service  (QoS)  constraints 

•  Selected  Department  of  Department  of  Defense  Architecture  Lramework  (DODAL) 
products,  including: 

o  The  Operational  View-5  (OV-5):  The  Operational  Activity  Model  depicts  the 
operations  that  are  normally  conducted  in  the  course  of  achieving  a  mission  or 
business  goal. 

o  The  OV-2:  Operational  Node  Connectivity  Description  identifies  the  key 
players  and  interactions  necessary  to  conduct  the  corresponding  operational 
activities. 

o  The  OV-3:  Operational  Information  Exchange  Matrix  describes  the 
information  exchanged  and  the  relevant  attributes  of  the  exchanges. 


14  A  semantic  tag  is  an  XML  tag  that  adheres  to  a  specific  format  and  provides  a  way  to  annotate  an  ontology  or 
other  resource  with  metadata.  Semantic  tags  can  be  used  to  map  separate  XML  Schemas  to  each  other. 

15  These  service  ontologies  have  been  developed  collaboratively  by  working  groups,  usually  associated  with  a 
standards  body  such  as  the  W3C.  They  are  not  part  of  the  NextGen  enterprise  ontology,  but  they  may  be  used  in 
conjunction  with  it. 
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When  existing  services  are  fully-provisioned,  that  improves  system  interoperability  and  helps  to 
ensure  that  the  services  are  discoverable,  understandable,  and  usable  as  intended,  even  by 
unanticipated  users. 

In  those  cases  where  information  exchanges  do  not  currently  exist  but  have  been  identified  as 
necessary  or  helpful  for  NextGen  implementation,  although  the  services  cannot  be  fully 
provisioned  as  described  above,  it  is  still  important  to  describe  them  and  to  register  those 
descriptions.  For  such  services,  the  Level  I  Provisioning  described  above  (Service  Metadata 
Card)  should  still  be  completed,  to  the  extent  possible,  because  this  information  will  be  used  in 
searches  to  find  the  planned  information  exchanges.  The  rest  of  the  material  registered  should 
focus  on  the  content  of  the  information  exchange.  This  could  include  ontology  elements  and/or 
selected  DoDAF  views  such  as  the  OV-5  (Operational  Activity  Model)  and/or  OV-3 
(Operational  Information  Exchange  Matrix). 

2.3  COI  Engagement  Teams 

The  COI  Engagement  Team  is  an  agile  development  team  that  can  rapidly  develop  the  products 
listed  above,  respond  quickly  to  changing  requirements,  and  make  continuous  improvements 
over  successive  development  cycles.  NextGen  stakeholders  comprise  a  diverse  community,  with 
widely  disparate  requirements,  no  centralized  authority,  and  varying  levels  of  COI  or  WG 
maturity.  The  use  of  COI  Engagement  Teams  is  intended  to  overcome  some  of  these  challenges 
by  implementing  a  coordinated  process  for  developing  a  net-centric  information  exchange 
environment  in  NextGen. 

A  COI  Engagement  Team  consists  of  permanent  members  and  adjunct  members.  The  permanent 
members  typically  come  from  JPDO,  are  officially  assigned  to  the  team,  and  can  be  assigned 
official  tasks.  On  the  other  hand,  adjunct  members  typically  come  from  the  COI  and/or  JPDO 
study  teams,  are  not  officially  assigned  to  the  team,  and  therefore  cannot  be  assigned  taskings  but 
rather  augment  the  team  in  order  to  provide  critical  skills,  expertise  and  insight.  The  adjunct 
members  include  subject  matter  experts  (SMEs),  partner  agency  personnel  and  others.  As  such, 
each  COI  Engagement  Team  is  a  unique,  cross-functional  team  composed  of  specialists,  each  of 
whom  brings  a  unique  set  of  skills  and  expertise  to  bear  on  the  shared  goal  of  developing  and 
provisioning  information  exchange  services.  COI  Engagement  Team  member  roles  include  the 
following: 


Team  Lead  Facilitates  and  leads  the  analysis  of  the  COI’s  information  exchanges. 

Ontologist  Develops  ontologies  and  provides  technical  expertise  for  associating  the 
real-world  concepts  and  their  relations  with  the  corresponding 
components  of  other  agencies  or  COIs. 
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Business  Documents  the  operational  and  systems  architecture  relevant  to  the 

Architect  selected  COI  information  exchanges  with  a  view  towards  ensuring  that 

the  business  and  information  technology  are  in  sync.  The  Business 
Architect  ties  the  COI-level  operational  and  systems  architecture  to  the 
JPDO  Enterprise  Architecture. 


2.4  COI  Engagement  Team  Responsibilities 

The  NCOD  COI  Engagement  Team  will  analyze  information  exchanges  for  the  purpose  of 
developing  or  compiling  the  NextGen  Enterprise  Ontology.  The  development  of  the  ontology  is 
part  of  Level  II  Semantic  Provisioning,  as  shown  in  Figure  1,  below.  If  a  COI  or  partner  agency 
has  an  existing  ontology,  the  NCOD  COI  Engagement  Team  will  make  every  effort  to  use  that 
ontology  in  the  NextGen  Enterprise  Ontology.  If  the  existing  ontology  is  lacking  definitions  or 
other  key  semantic  information,  the  COI  Engagement  Team  will  work  with  the  COI  to  develop 
them.  If  there  are  multiple  competing  ontologies,  the  COI  Engagement  Team  will  work  with  the 
COI  to  select  one  or  a  subset  of  multiple  ontologies  for  the  COI  ontology.  Note  that  the  COI 
ontology  cannot  contain  competing  or  duplicative  ontologies,  however  the  competing  ontologies 
can  be  mapped  to  each  other  so  that  whichever  ontology  someone  is  using,  they  can  still  use 
materials  based  on  the  other  ontology. 

The  NCOD  COI  Engagement  Team  will  also  identify  and  provision  existing  information 
exchange  services  for  reuse  by  the  NextGen  community.  Identifying  and  provisioning  existing 
services  provides  immediate  business  value  by  allowing  the  JPDO  to  quickly  improve  data 
accessibility  for  a  wide  range  of  NextGen  stakeholders.  This  approach  leverages  capabilities 
already  in  place,  helps  to  ensure  reuse  of  services,  identifies  the  gaps  between  existing 
capabilities  and  the  information  exchange  requirements  captured  through  operational  activity 
analysis  and  modeling.  These  analyses  also  enable  the  COI  Engagement  Teams  to  develop  the 
information  exchange  architecture  products  necessary  to  understand  and  provision  existing 
systems  or  to  support  the  creation  of  new  services.  The  provisioning  of  services  is  part  of  the 
Level  II  and  III  Provisioning,  as  shown  in  Figure  1,  below. 


3.0  Overview  of  COI  Engagement  Process 

Prior  to  starting  a  COI  engagement,  the  COI  Engagement  Team  works  with  NCOD  leadership  to 
identify  a  COI  Lead,  draft  and  execute  a  COI  Project  Charter,  perform  background  research  to 
identify  important  domain  objects  (people,  places,  and  things),  processes,  operational  activities, 
and  candidate  information  exchanges.  Once  a  COI  Lead  has  been  identified  and  a  COI  Project 
Charter  has  been  executed,  the  COI  Engagement  Team  works  with  the  COI  Lead  to  prioritize 
information  exchanges  to  be  analyzed,  and  to  identify  business  and  technical  SMEs. 


Note  that  in  some  cases,  if  a  COI  Lead  cannot  be  identified  in  a  timely  fashion,  NCOD  may 
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choose  to  exercise  one  of  the  following  options  as  a  contingency: 

1.  Postpone  the  engagement  with  that  COI  until  a  COI  Lead  is  identified 

2.  Assign  a  government  employee  to  serve  as  a  proxy  for  the  COI  Lead 

In  keeping  with  the  iterative  methodology,  the  COI  Lead  and/or  COI  SMEs  select  a  few  key 
information  exchanges  as  the  focus  for  each  engagement.  The  COI  Engagement  team  then 
reviews  the  JPDO  Enterprise  Architecture  (EA)  in  order  to  identify  elements  that  are  related  to 
the  selected  information  exchanges.  The  team  will  re-use  or  reference  those  elements  in  their 
work,  as  appropriate.  In  many  cases,  even  where  they  deal  with  the  same  or  similar  subject 
matter,  there  will  be  a  difference  in  granularity  between  the  JPDO  EA  and  the  COI  Engagement 
Team’s  work,  i.e.  the  JPDO  EA  may  deal  with  something  at  a  high  level  (overview),  and  the  COI 
Engagement  Team  may  be  working  at  a  lower  level  of  detail. 

Prior  to  engaging  with  SMEs,  the  COI  Engagement  Team  prepares  a  list  of  questions  designed  to 
elicit  expert  knowledge  from  them  about  the  information  exchanges  that  have  been  selected  for 
the  engagement.  The  COI  Engagement  Team  also  gathers  information  about  the  existing  and 
required  infrastructure  for  data  communications  and  cyber  security. 
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Figure  1:  COI  Engagement  Overview 
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As  depicted  in  Figure  1,  after  reviewing  the  JPDO  EA  and  completing  other  preparatory 
research,  the  COI  Engagement  Team  interviews  the  COI  Lead  and  SMEs.  As  a  general  rule,  the 
entire  COI  Engagement  Team  will  participate  in  the  SME  interviews.  The  rationale  for  this  is 
that  each  team  member  brings  a  different  set  of  skills  and  expertise  to  the  team,  so  it  is  important 
for  each  of  them  to  interact  directly  with  each  SME.  As  the  COI  Engagement  Team  interviews 
SMEs,  it  analyzes  the  results  of  the  interviews  and  synthesizes  the  SME  inputs,  together  with  the 
relevant  items  from  the  JPDO  EA,  into  a  set  of  information  exchange  architecture  and  ontology 
products  that  describe  the  information  exchange(s).  These  products  are  described  in  Section  5 
“Review  of  COI  Engagement  Products.”  As  the  team  continues  to  interview  additional  SMEs, 
the  products  evolve  to  incorporate  the  additional  feedback.  In  general,  as  the  COI  Engagement 
Team  constructs  draft  information  exchange  architecture  diagrams,  ontologies,  or  other  products, 
they  review  them  iteratively  with  selected  SMEs  and/or  the  COI  Lead  in  order  to  ensure  that  the 
products  are  accurate  and  complete.  When  the  NextGen  Enterprise  Ontology  and  any  message 
transformations16  have  passed  internal  testing  and  been  reviewed  with  the  COI,  the  COI 
Engagement  Team  uses  the  Semantic  Metadata  Portal17  to  update  the  Semantic  Metadata  Catalog 
with  the  latest  versions  of  the  NextGen  Enterprise  Ontology  and  message  transformations. 


4.0  Technical  Approach18 

The  COI  Engagement  Team  engagement  will  adhere  to  established  standards  and  best  practices. 

These  include  the  following: 

•  Air  Force  Community  of  Interest  ( COI)  Primer  1.0  (dated  12  July  201 1),  which  addresses 
production  of  requirements  for  service  acquisition  and  implementation,  as  well  as 
production  of  common  vocabularies 

•  DOD  Net-Centric  Data  Strategy  (dated  9  May  2003)  and  Net-Centric  Service  Strategy 
(dated  4  May  2007),  which  provide  guidelines  for  information  sharing,  ontology 
development,  and  implementation  of  data  services 

•  DOD  Architecture  Framework  (DODAF)19 ,  an  Enterprise  Architecture  reference  model 


16  A  message  transformation  defines  a  method  to  permit  systems  with  incompatible  data  formats  to  share  data. 
Message  transformations  are  often  done  with  XML  Stylesheet  Language  Transformation  (XSLT)  files. 

17  The  Semantic  Metadata  Portal  is  a  web  interface  through  which  users  can  access  the  Semantic  Metadata  Catalog. 
With  the  appropriate  access  controls,  it  allows  one  to  view  materials  that  have  been  registered  in  the  Semantic 
Metadata  Catalog,  or  to  register  items  in  the  Semantic  Metadata  Catalog,  if  appropriate.  Both  the  Semantic 
Metadata  Portal  and  the  Semantic  Metadata  Catalog  are  discussed  in  greater  detail  in  Section  6.1  Semantic 
Metadata  Catalog  and  Portal. 

18  The  COI  Engagement  Plan  specifically  uses  a  DoD  net-centric  approach  as  DoD  approach  is  mature  and  well 
understood. 

19  The  COI  Engagement  Team  will  coordinate  with  the  NextGen  Enterprise  Architecture  Team  regarding  DODAF 
version  1.5  vs.  2.0. 


Joint  Planning  and  Development  Office 


10 


JPDO  Net-Centric  Operations  Division 

Community  of  Interest  Engagement  Plan 


•  Web  Ontology  Language  ( OWL)  [published  by  the  World  Wide  Web  Consortium 

(W3C)],  which  provides  a  standard  top-level  ontology  and  a  framework  for  developing 
the  enterprise  and  domain- specific  ontologies  that  will  facilitate  use  of  NextGen  data 
services 

4.1  Ontology 

The  NextGen  Enterprise  Ontology  serves  as  a  shared  model  that  sets  forth  the  precise  nature  of 
the  data  elements  (such  as  people,  places,  things  and  activities)  about  which  NextGen  COIs 
exchange  information.  The  ontology  focuses  on  meaning  or  semantics.  Thus,  it  provides  an 
excellent  mechanism  for  semantically  associating  (in  a  machine-readable  format)  the  data 
elements  of  different  COIs  where  data  elements  have  different  names  but  refer  to  the  same  thing. 
For  example,  the  atmospheric  phenomenon  that  is  sometimes  referred  to  as  the  “aurora  borealis” 
is  also  known  as  the  “northern  lights.”  Regardless  of  which  term  is  used,  the  phenomenon 
referred  to  is  the  same.  In  other  words,  different  communities  may  use  the  same  word  to  describe 
different  things.  An  ontology  representing  the  phenomenon  will  contain  only  one  representation 
of  the  phenomenon  itself,  but  that  representation  may  be  associated  with  multiple  data  services 
which  use  different  data  element  names  to  refer  to  it.  Data  providers  need  only  map  their  data 
elements  to  the  appropriate  concept  in  the  ontology  once,  but  by  doing  so,  will  thereby 
effectively  map  their  own  data  elements  to  any  other  semantically  identical  data  elements  that 
have  also  been  associated  with  the  NextGen  Enterprise  Ontology.  A  similar  semantic  issue 
occurs  when  different  COIs  use  the  same  term  to  mean  different  things  (e.g.  “mercury”  as  an 
element  or  as  a  car).  Perhaps  in  one  ontology,  “mercury”  is  defined  as  an  element,  and  in  the 
other  ontology  “element  mercury”  is  defined  as  the  element,  while  “mercury”  is  defined  as  a  type 
of  car.  In  this  case,  one  would  map  “mercury”  from  the  first  ontology  to  “element  mercury”  from 
the  second  ontology. 

In  some  cases,  the  COI  and/or  NextGen  partner  agencies  may  have  already  developed  a  domain 
ontology  in  which  its  domain  objects  are  represented.  In  such  cases,  the  COI  Engagement  Team 
will  work  with  the  COI  or  partner  agency  to  register  the  ontology  in  the  NextGen  Semantic 
Metadata  Catalog  and  to  align  the  COI’s  or  partner  agency’s  ontology  with  the  NextGen 
Enterprise  Ontology.  In  cases  where  there  is  no  domain  ontology,  and  the  domain  objects  and 
operational  activities  are  not  already  part  of  the  NextGen  Enterprise  Ontology,  the  team  will 
extend  the  NextGen  Enterprise  Ontology  to  include  them. 

4.2  DODAF  Products 

The  COI  Engagement  Team  develops  the  information  exchange  architecture  using  DODAF 
views  to  illustrate  the  information  exchanges  identified  through  the  analysis.  The  high-priority 
domain  objects  and  processes  identified  by  the  COI  Lead  serve  as  the  starting  point  for  the  COI 
Engagement  Team’s  analysis.  For  example,  in  the  Weather  COI,  a  meteorological  report  from  a 
weather  sensor  and  a  pilot’s  observation  report  might  be  selected  as  key  information  exchanges. 
The  COI  Engagement  Team  then  analyzes  these  information  exchanges  through  documentation 
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and  successive  interviews  with  SMEs.  Based  on  this  analysis,  the  team  develops  appropriate 
DODAF  products  which  describe  the  type  of  information  exchanged  and  the  technical 
requirements  -  latency,  service  levels,  etc.  -  for  these  exchanges. 


20 

5.0  Review  of  COI  Engagement  Products 

Figure  2  displays  the  COI  Engagement  products  that  result  from  the  synthesis  work  described  in 
Section  3  and  shows  how  those  products  relate  to  each  other.  Each  product  is  depicted  by  a 
rectangular  box,  and  the  arrows  roughly  indicate  dependencies  among  the  products.  Upon 
approval  by  the  JPDO  approval  process21,  all  of  the  Engagement  Products  are  registered  (as 

described  in  Section  6.0  Registration  of  Products”)  in  the  Semantic  Metadata  Catalog  and 
integrated  into  the  JPDO  EA.  The  following  sections  provide  a  brief  explanation  of  the  products 
that  result  from  a  typical  COI  engagement. 
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Figure  2:  Overview  of  COI  Engagement  Products 


20  The  COI  products  will  be  developed  in  conjunction  with  the  NextGen  Chief  Architecture  and  the  relevant 
NextGen  partners. 

21  The  relevant  IPDO  approval  process  will  be  used  to  approve  existing  products  for  use  with  NextGen. 
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5. 1  Documentation  of  Business  Processes 

The  COI  Engagement  Team  begins  with  the  relevant  artifacts  from  the  JPDO  EA  and  input  from 
Subject  Matter  Experts  (SMEs),  as  shown  in  the  far  left  of  Figure  2.  The  team  may  prepare  a 
Business  Process  Model  Notation  (BPMN)~  diagram  up  front  if  the  team  believes  that  such  a 
diagram  will  be  a  useful  tool  that  will  assist  them  in  preparing  the  DODAF  operational  views. 

The  Operational  Activity  Model  (OV-5),  which  is  part  of  the  business  process  analysis  as  shown 
in  Figure  2,  describes  the  operations  that  are  normally  conducted  in  the  course  of  achieving  a 
mission  or  a  business  goal.  It  describes  capabilities,  operational  activities  (or  tasks),  input  and 
output  (I/O)  flows  between  activities,  and  I/O  flows  to/from  activities  that  are  outside  the  scope 
of  the  architecture.  The  OV-5  is  based  on  existing  documentation  and/or  SME  input. 

The  Operational  Resource  Flow  Description  (OV-2),  which  is  also  part  of  the  business  process 
analysis  as  shown  in  Figure  2,  depicts  Operational  Needlines  that  indicate  a  need  to  exchange 
resources  (e.g.,  information,  funding,  personnel,  or  materiel).  The  main  features  of  this  product 
are  the  operational  nodes  and  the  needlines  between  them  that  indicate  a  need  to  exchange 
information.  The  product  indicates  the  key  players  and  the  interactions  necessary  to  conduct  the 
corresponding  operational  activities  of  the  OV-5.  The  selection  of  information  exchanges  drives 
which  operational  activities  will  be  documented. 

5.2  Documentation  of  Information  Exchanges 

The  COI  Engagement  Team  will  typically  document  the  information  exchanged  along  with  the 
relevant  attributes  of  the  exchanges  in  the  form  of  a  DODAF  OV-3-  Operational  Resource  Flow 
Matrix,  shown  as  part  of  the  activity  to  list  information  exchanges  in  Figure  2.  The  OV-3 
identifies  the  resource  transfers  that  are  necessary  to  support  operations  to  achieve  a  specific 
operational  task.  The  OV-3  details  Resource  Flow  exchanges  by  identifying  which  Operational 
Activity  and  locations  exchange  what  resources,  with  whom,  why  the  resource  is  necessary,  and 
the  key  attributes  of  the  associated  resources.  The  OV-3  identifies  resource  elements  and  relevant 
attributes  of  the  Resource  Flows.  It  then  identifies  the  Operational  Activities  in  which  those 
Resource  Flows  participate,  whether  as  the  information  producer  or  consumer.  More  specifically, 
the  OV-3  associates  the  Resource  Flows  with  the  particular  Needlines  that  they  satisfy  for  the 
Operational  Activity. 

5.3  Documentation  of  Systems  Communications  and  Requirements 

The  Business  Architect  is  responsible  for  documenting  existing  services.  The  required  level  of 
detail  for  the  documentation  is  based  on  the  business  needs,  the  availability  and  quality  of  system 


22  Business  Process  Modeling  Notation  (BPMN)  is  a  method  of  illustrating  business  processes  in  the  form  of  a 
diagram  similar  to  a  flowchart.  It  is  not  a  DoDAF  product,  but  because  it  encapsulates  the  information  from  a  few 
DoDAF  products,  it  can  be  helpful  in  preparing  those  DoDAF  products. 

23  In  DODAF,  a  needline  represents  an  information  exchange  or  communication  between  two  operational  nodes.  An 
operational  node  is  an  entity  that  produces,  consumes,  or  manipulates  information. 
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documentation,  and  the  availability  of  knowledgeable  SMEs.  In  general,  the  COI  Engagement 
Team  will: 

•  Obtain  and  review  system  documentation 

•  Interview  knowledgeable  SMEs 

•  Develop  system  architecture  products  necessary  to  understand  and  provision  existing 
systems 

•  Validate  system  architecture  products  with  SMEs 

•  Compile  and  deliver  system  architecture  products 

The  COI  Engagement  Team  will  leverage  existing  system  documentation  as  much  as  possible.  In 
many  cases,  system  documentation  alone  may  not  provide  a  complete  and  accurate  picture  of  the 
existing  system  capabilities.  In  such  cases,  the  system  documentation  will  guide  the  interview 
process  by  providing  background  information  and  helping  the  team  develop  targeted  questions  to 
obtain  more  information  or  to  seek  clarifications  from  technology  SMEs.  In  general,  the 
following  DODAF  products  are  developed  during  the  analysis  of  existing  systems: 

•  Systems  Interface  Descriptions  (Systems  View-1)  (SV-1) 

•  Systems  Communications  Description  (SV-2) 

•  Systems  Functionality  Description  (SV-4) 

The  SV-1  addresses  the  composition  and  interaction  of  systems.  System  interface  descriptions 
link  together  the  operational  and  systems  architecture  models  by  depicting  how  resources  are 
structured  and  interact  to  realize  the  logical  architecture  specified  in  an  operational  resource  flow 
description.  The  SV-2,  shown  as  the  systems  communication  description  in  Figure  2,  specifies 
the  system  resource  flows  between  systems  and  the  protocol  stacks  used  in  connections.  A  key 
element  of  the  SV-2  is  the  documentation  of  cyber  security  requirements  that  enable  secure 
information  exchanges.  The  SV-4,  shown  as  the  requirements  document  in  Figure  2,  specifies  the 
functionality  of  resources  in  the  system  architecture,  including  functional  resources,  systems, 
performer  and  capabilities. 

5.4  Extensions  to  the  NextGen  Enterprise  Ontology 

Described  at  a  high  level  in  Section  2.1,  the  NextGen  Enterprise  Ontology  is  the  overarching 
ontology  that  includes  all  the  COI  ontologies  that  have  been  vetted  through  the  NCOD  COI 
Engagement  Team  process.  In  addition,  it  may  include  high-level  ontologies  such  as  an  upper- 
level  ontology^  that  help  to  organize  the  COI-specific  content  in  a  consistent  and  reusable 
manner.  It  is  depicted  as  part  of  Level  III  provisioning  in  Figure  2.  The  primary  inputs  into  the 
Enterprise  Ontology  for  each  COI  engagement  are  the  elements  from  each  information  exchange. 


2 :  An  upper-level  ontology  is  an  ontology  which  describes  very  general  concepts  that  are  the  same  across  all 
knowledge  domains.  The  most  important  function  of  an  upper  ontology  is  to  support  very  broad  semantic 
interoperability. 
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These  are  identified  in  1)  the  information  exchange  elements  in  OV-3  Operation  Resource  Flow 
Matrix  and  2)  the  data  elements  from  existing  information  exchange  services.  These  elements 
represent  an  initial  set  of  terms  to  be  defined  in  and  incorporated  into  the  NextGen  Enterprise 
Ontology. 

The  COI  Engagement  Team  gives  each  element  in  the  NextGen  Enterprise  Ontology  a  logical 
definition,  rigorously  utilizing  the  structure  of  the  taxonomy  in  the  formulation  of  its  definitions 
when  possible.  Each  logical  definition  is  associated  with  an  authoritative  source  from  which  the 
definition  is  derived.  The  authoritative  source  may  be  a  doctrinal  source  or  a  SME.  Where 
possible,  the  team  will  use  existing  ontologies  in  order  to  define  the  semantics  of  an  information 
exchange  element.  The  use  of  existing  ontologies  is  intended  to  improve  semantic 
interoperability.  For  example,  the  ISO-3166  standard  is  widely  used  to  refer  to  geographic 
regions  around  the  world.  By  re-using  ISO-3166,  references  to  countries  by  the  COI  will  be 
understandable  by  the  many  other  agencies  that  use  ISO-3166.  Once  the  information  objects  and 
their  attributes  have  been  defined  in  the  NextGen  Enterprise  Ontology,  the  extensions  are 
validated  for  content  and  consistency. 

The  NextGen  Enterprise  Ontology  can  be  used  as  the  basis  for  message  schemas,  and  in  fact, 
doing  this  ensures  that  the  message  schemas  are  consistent  with  the  semantics  of  the  ontology. 

5.5  Identify  Service  Gaps 

The  COI  Engagement  Team  may,  based  upon  COI  need,  provide  a  high-level  description  of 
services  that  are  needed  by  the  community.  These  service  gaps  would  be  identified  by  comparing 
the  Information  Exchange  Requirements  in  the  OV-3  with  the  COI’s  existing  services.  Note  that 
in  some  cases,  the  community  may  already  have  identified  these  gaps.  In  that  case,  this  step  of 
the  process  may  be  skipped. 

5.6  Provision  Existing  Services 

In  cases  where  there  are  existing  web  services,  two  additional  artifacts  are  produced: 

1)  Message  transformations  that  tie  the  web  services’  native  message  schemas  to  the 
NextGen  Enterprise  Ontology.  This  is  generally  done  with  an  extensible  Stylesheet 
Language  Transformation  (XSLT) 

2)  A  Service  Ontology  defined  to  support  service  discoverability,  under standability,  and 
interoperability.  This  is  accomplished  by  representing  services  within  an  ontology  and 
annotating  these  representations  with  content  from  the  NextGen  Enterprise  Ontology 
using  Semantic  Annotations  for  WSDL  and  XML  Schema  (SAWSDL) 


25  These  steps  represent  the  technical  validation,  or  testing,  of  the  Ontology.  The  content  of  the  ontology  is  validated 
through  the  COI,  WG,  and/or  SMEs. 
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6.0  Registration  of  Products 

6. 1  Semantic  Metadata  Catalog  and  Portal26 

A  Semantic  Metadata  Catalog  and  Portal  will  be  created  to  support  the  cataloging  and  reuse  of 
services.27  The  Semantic  Metadata  Catalog  is  federated  with  agency  service  registries  and  thus 
provides  a  single  source  for  discovering  products.  It  stores  metadata  about  products  and  points  to 
where  they  are  stored.  The  Semantic  Metadata  Portal  is  a  web-based  portal  that  allows  users 
access  to  the  Semantic  Metadata  Catalog  to  view,  add,  or  update  catalog  records.  The  following 

no 

products  (if  they  exist)  will  be  registered  in  the  Semantic  Metadata  Catalog  and  Portal  : 

•  A  catalog  of  documented  services 

•  WSDL  files  for  documented  services  and  newly  defined  services 

•  SAWSDL  documents  containing  semantic  annotations  that  link  to  the  NextGen 
Enterprise  Ontology. 

•  XSD  documents  that  contain  the  message  schemas  based  on  the  NextGen  Enterprise  or 
Domain  Ontology 

•  RDF/OWL  document  that  contains  the  NextGen  Enterprise  or  Domain  Ontology 

•  OV-2,  OV-3,  and  OV-5 

•  SV-1,  SV-2,  and  SV-4 

•  All  View  2  (AV-2)  Integrated  Dictionary 

•  Service  Memorandum  of  Agreement  (MO A) 


7.0  COI  Engagement  Phases 

Based  on  JPDO  plans  for  engaging  with  JPDO  communities,  the  following  represents  the  phased 
order  in  which  the  COI  Engagement  Teams  tentatively  plan  to  engage  the  various  JPDO  COIs  or 
working  groups.  This  schedule  is  subject  to  change  as  needed  to  support  JPDO  plans. 

Phase  1 

•  Weather 

•  Integrated  Surveillance 

Phase  2 

•  Unmanned  Aircraft  Systems 


2b  Products  within  the  Semantic  Metadata  Catalog  and  Portal  will  be  referenced/listed  in  the  NextGen  Enterprise 
Architecture  and  will  also  be  referenced  in  the  Joint  Planning  Environment.  Any  updated  to  these  products  will  be 
managed  via  the  NextGen  Configuration  Management  (CM)  process. 

21  At  this  point,  it  has  not  been  decided  who  will  create  and/or  own  the  Semantic  Metadata  Catalog  and  Portal. 

~s  These  products  will  be  coordinated  with  the  JPDO  Enterprise  Architecture  Team. 
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Phase  3 

•  Flight  &  Flow 

•  Airport  Business  and  Operations 

•  Safety 

•  Trajectory  and  Performance -Based  Operations 

•  Layered  Adaptive  Security 

•  Environmental  Management 

•  Positioning,  Navigation,  and  Timing 

•  Airline  Business  and  Operations 

•  Special  Use  Airspace 


8.0  Post  COI  Engagement  Lessons  Learned  and  Refinement 

At  the  end  of  each  COI  Engagement,  the  team  will  conduct  a  post-engagement  lessons  learned 
activity.  This  activity  is  essential  to  refine  the  engagement  process  to  better  serve  the  COI 
Engagement  Team  and  community  with  a  more  efficient  and  effective  engagement  process.  The 
goal  is  to  capture  lessons  learned  from  the  post-engagement  while  they  are  still  fresh  in  peoples’ 
minds.  The  results  are  summarized  and  recommendations  are  passed  on  to  future  teams.  The 
lessons  learned  are  also  used  to  refine  the  overall  engagement  process. 

If  the  COI  Engagement  Team,  through  the  course  of  the  engagement,  identifies  any  necessary 
changes  to  the  COI  Engagement  Process  as  described  in  this  document,  the  team  will  also  update 
this  document  at  the  end  of  the  COI  engagement. 
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9.0  Glossary 


Agile  Development  A  development  process  based  on  iterations 

where  requirements  and  solutions  evolve 
through  collaboration  between  self-organizing 
cross-functional  teams. 


Authoritative  Data  Source 


Business  Architect 


Business  Process 


Community  of  Interest  (COI) 


COI  Engagement  Team 


Concept 

Enterprise  Architecture 


Information  Exchange 


A  data  source,  potentially  identified  by  the  COI 
Engagement  Team,  that  is  designated  by  a  COI 
and/or  SMEs  as  providing  authoritative  data 
and/or  definitions. 

An  architect  who  documents  the  operational 
and  systems  architecture  relevant  to  the  COI 
with  a  view  towards  ensuring  that  the  business 
and  information  technology  are  in  sync.  Ties 
the  COI-level  operational  and  systems 
architecture  to  the  JPDO  Enterprise 
Architecture. 

A  structured  collection  of  tasks  that  produces  a 
service  or  product. 

A  community  of  people  who  share  common 
data  and/or  services. 

A  group  composed  of  a  Team  Lead,  an 
Ontologist,  and  a  Business  Architect.  This 
group  is  formed  to  produce  the  products 
necessary  to  provision  a  new  or  existing  service 
based  on  information  objects. 

A  defined  term  used  in  a  business  model. 

A  rigorous  description  of  the  structure  of  an 
enterprise,  its  decomposition  into  subsystems, 
the  relationships  between  the  subsystems,  the 
relationships  with  the  external  environment,  the 
terminology  to  use,  and  the  guiding  principles 
for  the  design  and  evolution  of  an  enterprise. 

A  description  of  a  kind  of  message  used  in  a 
business  process,  combined  with  other 
information  such  as  the  service  contract. 
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Information  Element  An  object  (or  term)  that  is  used  in  one  or  more 

information  exchanges  in  order  to  convey  facts 
about  a  real-world  entity  such  as  a  person, 
aircraft  or  weather  phenomenon. 

Infrastructure  Specification  A  description  of  the  logical  or  physical  systems 

of  a  business. 

Net-Centric  Operations  Division  A  division  of  the  Joint  Planning  Development 

Office  tasked  with  supporting  information 
sharing  amongst  communities  of  interest  via 
semantic  service-oriented  architecture. 


Ontologist 

Ontology 

Policy 

Semantics 

Service  Contract 

Taxonomy 

Team  Lead 


A  technical  expert  who  builds  models  of  real- 
world  concepts,  their  terms,  and  their  meanings. 

A  formal  representation  of  the  knowledge 
within  a  domain  by  a  set  of  concepts  and  the 
relationships  between  those  concepts. 

A  recommendation  or  mandate  to  implement  a 
particular  technical  standard. 

The  interpretation  of  the  meaning  of  terms  in  a 
particular  context. 

The  formalization  of  the  participants  and  the 
rules  of  engagement  for  collaboration. 

The  set  of  classes  in  an  ontology  and  their 
relationships  according  to  the  subclass  relation. 

A  technical  expert  who  facilitates  and  leads  the 
analysis  of  the  COI’s  information  exchanges. 


Technical  Standard  A  controlled  artifact  maintained  by  a  standards 

body. 

Upper-level  Ontology  An  ontology  which  describes  very  general 

concepts  that  are  the  same  across  all  knowledge 
domains.  The  most  important  function  of  an 
upper  ontology  is  to  support  very  broad 
semantic  interoperability. 

Web  Ontology  Language  (OWL)  A  family  of  knowledge  representation 

languages  used  for  authoring  ontologies. 
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A  multi-agency  collaboration  focused  on 
information  sharing  in  a  particular  domain. 
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10.  Acronyms 

BPMN 

Business  Process  Modeling  Notation 

COI 

Community  of  Interest 

DOD 

Department  of  Defense 

DODAF 

DOD  Architecture  Framework 

EA 

Enterprise  Architecture 

I/O 

Input/Output 

JPDO 

Joint  Planning  and  Development  Office 

MOA 

Memorandum  of  Agreement 

MSM 

Minimum  Service  Model 

NCOD 

Net-Centric  Operations  Division 

NETE 

Net-Enabled  Test  Environment 

NextGen 

Next  Generation  Air  Transportation  System 

OV 

Operational  View  (DODAF) 

OWL 

Web  Ontology  Language 

QoS 

Quality  of  Service 

RDF 

Resource  Description  Framework 

RDFS 

Resource  Description  Framework  Schema 

SAWSDL 

Semantic  Annotations  for  WSDL  and  XML  Schema 

SME 

Subject  Matter  Expert 

SLA 

Service  Level  Agreement 

SV 

Systems  View  (DODAF) 

XSLT 

extensible  Stylesheet  Language  Transformation 

WG 

Working  Groups 

WSDL 

Web  Services  Description  Language 

WSMO 

Web  Service  Modeling  Ontology 

WS-Policy 

Web  Services  Policy 

XML 

extensible  Markup  Language 
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